答案就是昨天留下的基礎設施管理員和DBA，但也只是可能而已。

先講基礎設施管理員，網路、硬體負載平衡器、Hypervisor、認證授權伺服器、DNS這些都是容器所仰賴的基礎設施，因為這些基礎設施是在容器層之下，所以理論上是不會受容器影響的。

但是呢？為了要更好的運用容器，若能在基礎設施層能提供更動態的供裝及設定方式，會有利於容器的動態供裝。畢竟容器還是要倚賴這些基礎設施，容器的調整（如：搬遷）可能需要搭配基礎設施的調整，來滿足組織的資訊規範。

比方說，容器平台一般都會建議搭配軟體定義網路(SDN)來讓容器搬遷時仍能有固定的IP位址。SDN也用來提供網路隔離功能，在多租戶共用時來滿足組織對資訊安全的要求。

如果原本的基礎設施就是架構在 AWS, Azure 等成熟的公雲上，會比較能夠和容器平台整合，基礎設施管理員也比較不需要學習新的知識。但如果原本的基礎設施是自建的，就會需要不少的 workaround，尤其是這些基礎設施還分屬多個不同機構管轄的時候...

再來講DBA，DB有幾個特點會削弱容器化帶來的效益，所以有時候並不是容器化的首選。

• 多數的RDB，若需要有Master-slave或是cluster架構，在現階段都還不適合容器化。
• 若DB的行程和資料不能動態綁定(Ex:若一個DB行程掛掉時可以自動啟另一個DB行程綁相同的資料)，也不適合容器化。
• 若DB的效能瓶頸是在I/O且沒有內建的scale out能力，容器化可能會降低效能。

但DB容器化也不是沒有好處的，如果在開發環境中需要搭配一個single instance的DB來測試，容器化的DB還是很好用的，可以輕易的重建。現階段容器化DB是用來作為一個可拋棄式的DB，在開發測試階段都有幫助，只是可能不適合規模較大或可用性要求較高的生產環境。

所以DBA還是應該懂些容器知識，甚至可以跟Middleware/Tool/Library管理員一樣，要會做些DB容器的環境樣板。

以上說明。

不過我們似乎還漏了一個地方。我們需要一個容器平台，這個容器平台該由哪個角色來管理呢？